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Title 

A Transaction Orientated Data Transport Mechanism for use in Digital Cellular 
5 Networks. 

Technical Field 

The present invention relates to wireless digital telecommunication and in particular to a 
10 system that provides narrow band data transport capability to Value Added Service 
Platforms ( VASP's). 

Background to the Invention 

15 Within the field of mobile digital telecommunications value added services, such 

as email, voice mail, unified and text messaging and other forms of data, are transferred 
between mobile handsets and service providers. Currently value added services are 
deployed over a number of transport bearers, including Short Messaging Service (SMS), 
Unstructured Supplementary Service Data (USSD), Circuit Switch Data (CSD), and 

20 Cellular Digit Packet Data (CDPD). Currently, the majority of deployed services use 
SMS especially within GSM. The traditional approach to providing (messaging) 
transport service is by using the Short Messaging Service Centre (SMSC) store and 
forward service typically provided through network based SMSC platforms. 

25 Figure 1 shows the interaction between a value added service provider 1 and a 

mobile station 10 connected to a network 2 using current methodologies. The value 
added service provider 1 generates data that is to be transmitted to a mobile station 10 
and responds to data that is receivedTrom the mobile station 10. The mobile handset or 
mobile station 10 is the terminal device in the mobile network 2 to which all data and 

30 voice communications for a particular subscriber in a network 2 is directed and from 
which all data and voice from a particular subscriber originates. A digital cellular data 
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packet transfer mechanism 3,. hereinafter referred to as a transport mechanism 3, which 
may comprise a short messaging entity and permanent store message switch layers 4, 
together with transport and relay layers 5, such as MAP and TCAP, which are both 
defined in accordance with known ETSI standards, is used to transfer the messages from 
5 the service provider 1 and the network 2. A layer is a set of services which are 

accessible via defined service points and these services are delivered by using internal 
functions of the layer and also using the services of other layers. Individual layers 4, 5 
may communicate with each other and with the network 3 using transaction based 
responses, i.e. where the first layer has control over the delivery of data, but such 
10 transaction based responses are currently not transparent, or available, to the value 
added service provider li 1 ' 

Adequate quality of service, particularly for applications which require high 
message throughput and low delivery latency, for example: automatic vehicle location 
15 service (AVLS) systems, gateway products, over the air provisioning and voice mail 
systems, is not always possible using this method. Current SMSC technology finds it 
difficult to meet these requirements. High capacity and robustness can be provided by 
some SMSC vendors but at a very high price. In general operators. are faced with the 
following issues when using SMSC technology for value added services: 
20 1 '* ' ■'- • ••■ 

* High cost of ownership - the maintenance time of SMSC is very high and costly 
Robustness - Because SMSC technology is overly complex (for a data transport 
role) robustness is difficult to achieve at the high data rates new services demand, 
Scalability - trying to introduce new services which place high volume messaging 
25 demahdson the SMSC are difficult to accurately- engineer and predict. 

Value added services based on SIM tool kit, Java card, HDML and TTML 
services ahd Wireless Application-Protocol (WAP) are all placing new demands on the 
SMS transport bearer and in particular the Short Message Service Centre's (SMSC's). 
30 This is leadihg^some operators to start looking at USSD as an alternative for more 
transaction based services, or trying to plan services against future technologies like 
GPRS. This will involve complete or partial upgrading/ replacement of hardware and 
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software components which ^expensive to implement. The new services all require the 
following functionality from a data bearer to provide a proper service: 

♦ High messaging volume capability 

* Low data turn around time (low latency) 

5 • Transaction like behaviour ( i.e. not store and forward but more real time behaviour) 

• Guaranteed grade of service - the ability to scale the product according to demand 
Robustness 

There is therefore a need for a system to address the problems associated with 
10 the provision of narrowband data transport capability to V AS platforms. Current 
transport market requirements include high volume messaging services and a low 
latency of data tranfer which is compliant with existing and emerging industry 
standards. These applications place less demands, on the ability of the transport layers to 
. store information and also require application side . control of the data transfer. 
15, Additionally with the emergence of wireless application protocol (WAP) there is a. need 
for WAP compliant systems. — ♦ 

Object of the Invention 



20 It is an object of the invention to provide a system that overcomes the 

aforementioned. problems and provides a fast efficient transaction based transport 
bearer for value added service providers. 

It is a further object to provide system that is optimised to provide, high 
25 performance, with little maintenance overhead.; It is a further object that such a system 
will be easily scaled and may be implemented in existing structures or architectures. 

It is a further object to provide a system that can extend the life of Short 
Message Service as a value addedservice bearer by making it more real time, and able 
30 to meet grade of service dernands.as well as providing, an easy way. to future proof the 
operators investment. , „ : ; 
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It is a further object to provide an interface to the system that is technology 
independent in that is provides access to the underlying bearer services offered by the 
network, for example USSD, SMS (IS41 and GSM) and in the future GPRS, which is 
transparent to the service provider. 

It is a further object to provide a system that supports multiple technologies of 
bearer service using the same interface.' 

Summary of the Invention 

' Accordingly the invention provides a method of allocating a communication 
transport channel for the transfer of data in a digital cellular network system comprising 
the steps of: ^ 
receiving a data transfer request, ' ■ 

comparing a first identifier orv said data transfer request to a series of stored reference 
values contained within at least one communication channel, 

comparing a second identifier ori said data transfer request to a sub-series of stored 
reference values, "' ' "■ ■ • * - 

determining an appropriate channel from said first comparison and allocating said data 
transfer request to the appropriate channel, and rejecting said data transfer request if said 
appropriate channel can not be determined. 

The method may further include the step of transferring said data to a destination 
address in a manner according to a set of predefined attributes and treatments stored in 
said appropriate channel. • 

• The method preferably further includes the preliminary step of making a 
connection comprising the steps of: - , 

obtaining a connection request from a service provider 
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comparing an identifier of said service provider to a predefined series of stored 
identifiers, 

comparing a check parameter from said service provider to a predefined series of check 
parameters * 
5 accepting said connection request when said identifier and said check parameter are in 
accordance with the stored identifier and predefined check parameter. 

The method may further comprise the steps of . * . . 
receiving a mobile originated data request, 
10 comparing a first mobile originated identifier; \vith a third stored reference value 

contained with at least one communication channel, 

determining if when first mobile originated identifier corresponds with the third 
; stored reference value whether said third stored reference value is stored in a 
multiplicity of communication channels, 
15 comparing a second mobile originated data, identifier with a fourth stored . 

reference values contained with tat least one communication channel, if the first mobile 
originated identifier does nqt corresponds with the third stored reference value, 
, . t comparing a third mobile originated data identifier with a fifth stored reference 
contained with at least one communication channel, if the second mobile originated 
20 identifier does not corresponds with the fourth, stored reference value, ,and rejecting said 
mobile originated data request if the third mobile identifier does not correspond with a 
fifth stored reference value, ; r , - . ^ 

determining if the second or third mobile identifiers correspond with a fourth or 
fifth stored reference value respectively, being stored in a multiplicity of communication 
25 channels, . . _ , > ^ 

cycling successive data requests to a service provider through -successive 
respective communication channels if the second or third mobile identifiers correspond 
with a fourth or fifth stored reference value respectively, being stored in a multiplicity of 
communication channels, : ■. , - : ; ■ - : 
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transmitting the data request to a service provider if the first or second or third 
mobile identifiers do not correspond with the third or fourth or fifth stored reference 
value, being stored in a multiplicity of communication channels: 

The invention additionally provides a layer in a digital cellular data packet 
transfer mechanism for use with a digital cellular telecommunications system 
comprising: 

means for receiving a data transfer request from a service provider, ' 

means for comparing a first identifier on said data transfer request to a series of 
stored reference values contained within at least one communication channel , 

means for comparing a second identifier on said data transfer request to a sub- 
series of stored reference values, .. . *. ....... 

means for determining an appropriate 'channel 'and treatment from said first 
comparison and said second comparison and allbcating said data transfer request to the 
appropriate channel. ; . - 

The layer may further comprise means' for configuring the data transfer request 
according to a set of predefined attributes and treatments stored in said appropriate 
channel and means for transferring said configured data to a destination address. 

The layer preferably fdrther comprises 

means for receiving a mobile originated' data request, 

means for comparing a first mobile originated identifier with a third stored 
reference value contained with dtieast one communication channel, 

means for determining if when first mobile originated identifier corresponds 
with the third'stored reference value whether said third' stored reference value is stored 
in a multiplicity of communication channels, 

means for comparing, a second niobile originated data identifier with a fourth 
stored reference values contained with atieast one communication channel, if the first 
mobile originated identifier does not corresponds with the third stored reference value, 
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mean? for comparing a third mobile originated data, identifier with a fifth stored 
reference contained with at least one communication channel, if the second mobile 
originated identifier does not corresponds with the fourth stored reference value, and 

means for rejecting said mobile originated data request if the third mobile 
5 identifier does not correspond with ,a fifth stored reference value, 

means for determining if the second or third mobile identifiers correspond with a 
fourth or fifth stored reference value respectively, being stored in a multiplicity of 
communication channels, , ^ 

means for cycling successive data requests, to a service provider through 
10 successive respective communication channels if the second or third mobile identifiers 
correspond with a fourth orfifth stored reference: yalue.respectively, being stored in a 
multiplicity of communication channels, 

means for transmitting the data request to ^ service provider if the first or second 
or.third mobile identifiers do not correspond with the third or fourth or fifth stored _ 
15 reference value, being stored in a multiplicity of communication channels. 

The invention may additionally provide lay er. for use with a bearer network in a 
telecommunications system comprising: 

connection means for defining hpw external systems communicate with the 
20 bearer network, and 

treatment means for defining how datzi received from the external system is 
mapped onto the bearer network. , _ , - ... 

A database structure may also be provided for use in a digital cellular 
25 . telecommunication system comprising: ^ . .. 

at least.one channel, having one or, more associated treatments whereby each 
channel comprises a series of definable attributes and each treatment comprises a series 
t of definable sub-fields such : that the /definition, of the attributes and sub-fields determines 
how data is transferred within the digital cellular network. 
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Preferably the definition of the attributes and sub-fields within specific channels 
and treatments is such that the database can be used with bearer networks selected from 
one of more of the following: 
Cellular Digital Packet Data (CDPD), 
5 Global System for Mobile Communications (GSM) Short Messaging Service, 
GSM Unstructured Supplementary Service Data (USSD), 
GSM General Packet Radio Service (GPRS), 

iDEN (Integrated Digital Enhanced Network.) Short Messaging Service, 
IS-136 GUTS (General UDP Transport Service), 
10 IS-136 Short Messaging Service, Time Division Multiple Access, 
IS-637 Short Messaging Service, Code Division Multiple Access, 
or other CDMA/ TDMA bearer networks. 

A transport mechanism suitable for use in a digital cellular network may 
15 additionally be provided, the mechanism comprising: " 

transport and relay layers for transporting and relaying data on a bearer network, 
and further comprising the layer as described above 

The invention also provides digital telecommunication system comprising: 
20 a service provider , 

a telecommunication network 

a transport mechanism for transferring data between the service provider and the 
network whereby the transport mechanism comprises a first layer suitable for 
interfacing with both the service provider and any other component layer of the 
25 transport mechanism, the first layer incorporating means for determining how data 
received from, and data destined for, the service provider is transferred. 

The first layer preferably comprises a series of channels, each channel having at 
least one treatment , the channels and associated treatments each comprising a set of 
30 data fields for determining how data allocated to the specific channel and treatment 
should be processed. 
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The definition of the data fields related to each channel and associated treatment 
suitably provides an interface to the system which is independent of the underlying 
bearer service. : 
5 • . , . . , • ^ . 

The definition of the data fields related to each, channel and associated 
treatments suitably enables the service provider of the system to transfer data in a 
transaction orientated manner. 

10 The number and definiticm of the r attributes is. preferably dependant on the 

application requirements and nature of the bearer technology. 

The attributes may be defined with reference to one or more of the following 
fields: - - > - - < - ■ 

15 Connection Descriptor . . . u . . 

Connection Reference 

Initial State ~ 1 } r • 1 " *' ' • 
Endpoint Address ^ . /t ^ . :r . . 

Endpoint Type 
20 User Ack Reqd 

. GSM PID : , : i,: >/c . • 

Password 

Connecting IP Address 

Alert Required ; . K 

25 

The subfields may be defined with reference to one or more of the following 

fields: 

Treatment ID 
Input Data Type 
30 Output Data Type ., 
GSM PID 

Fragmentation Type 
GSM Reply Path 
MWI Service Type 
35 - MW! Indication Group , ; : * 4 1 . • 

Message Class - * . - - , ; L : ■•■ - ■ v ; 
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The system may preferably . further comprise means for operating and 
configuring the system including a remote operation and management interface, access 
to which is preferably via a system administration terminal which may be operated 
using remote object invocation. * 

The system administration terminal preferably utilises at least one graphical user 
interface screen. 

Configuration and management of the signalling interface is preferably through 
the means for operating and configuring the system. 

Brief Description of the Dra wings 

Figure 1 is a schematic of a known digital cellular telecommunications system, 
Figure 2 is. a schematic of a digital cellular telecommunications system according to the 
. present invention, .'- t ; } : ' 

Figure 3 is a variant on the schematic of Figure 2, . 

Figure 4 shows the internal structure of an SMX layer according to the present invention 
Figure 5 shows the internal structure of a channel and associated treatment, 
Figure 6 is a flow chart showing a connection request according to the present 
invention, 

Figure 7 is a flow chart showing a data transfer request according to the present 
invention, -* --\ -u.;^: 

Figure 8 is a flow chart showing the routing of mobile originated data according to the 
* present invention, . - / i;; 

Figure 9 is a data flow; schematic. showing a data transfer request acknowledging 
successful transfer according to* the present invention, 

Figure ,10 is a data flow schematic showing a. data transfer request not. acknowledging 
successful transfer according to the present/invention 

Figure 11; is a da ta .flow schematic: showing; an example of an error occurring during data 
transfer according to the .present invention, . . . , - 
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Figure 12 is a data flow schematic showing an example of an error occurring during data 
transfer and a subsequent generation of alerts indicating that the error condition is no 
longer operable according to the present invention 

Figure 13 is a flow chart showing a possible internal mechanism for the generation of 
5 alerts according to the present invention, 

Figure 14 is a data flow schematic showing the transfer of two data packets according to 
different treatments according to the present invention, 

Figure 15 is a data flow schematic showing an example of message fragmentation 
according to the present invention, r *- 
10 Figure 16 is a data flow schematic showing an example' of message concatenation 
according to the present invention, 

Figure 17 is a flow chart showing a selective transmission operation according to the 
present invention, 

Figure 18 is a schematic showing the adaptation T of a single SMX layer to transfer data 
15 -. .\over a number of possible bearer networks according to the present invention, v ^ 
Figure 19 is a schematic of an internal structure of an SMX layer incorporating a storage 
cache for storing billing related information, and * - 

Figure 20 is a schematic illustrating the incorporation of a billing platform into a digital 
cellular telecommunication system having the storage cache of Figure 19 - - $ 

20 .« ' • " - ' " * ' 

Detailed Description of the Drawings 

The invention provides a mobile telecommunications system 11, shown in figure 
2, suitable for an application specific interface ;for the delivery of data in a digital 
25 cellular mobile network. In order to provide such an interface a transport mechanism 30 
is layered in a manner which separates the network and technology specific detail from 
the external interface, value added service provider or SMX user 1. This is achieved by 
* replacing the short messaging entity and permanent store layers 4 associated with 
traditional transport mechanisms with a transport layer 6, hereinafter referred to the 
30 SMX or SMX layer. Figured shows the incorporation of SMX 6 within the transport 
mechanism 3 illustrated in Figure 1 arid described in the section r background of the 
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invention.- The SMX 6 is a transport layer for the transmission of data to and from 
mobile handsets. The layer 6 may be driven from a higher level protocol layer such as a 
session layer or application layer, or directly from the VASP or SMX User 1, and 
communicates with these layers in a transaction orientated manner. The primary purpose 
5 of the SMX 6 is to provide a secure, reliable, error resilient, bearer independent 

transport layer interface for mobile data applications. The layer 6 interacts with the other 
components of the transport mechanism 30 and is designed as an interface that accepts 
variable length data from SMX User applications and transmits this data using an 
available bearer to a mobile station. In addition the layer may accept data from a mobile 
10 station 10 and transmit it to a SMX User 1/ 

The incorporation of the SMX 6, as a component of the transport mechanism 30 
to enable data connectiohs.to mobile users in a mobile network, within a mobile 
telecommunication systfem 11 is illustrated in Figure 3. The same reference numerals are 

15 used for similar structures. The SMX User ! communicates with a mobile station'or 

handset 10 via the transport mechanism 30 and the network 2; The transport mechanism 
30 comprises the existing known transport and relay layers, such as the MAP and TCAP 
layers 5 and also incorporates the SMX layer 6. These layers 5, 6 interact, using a 
physical layer appropriate to the relay layer on the bearer network/ with the signalling 

20 network 2, which in the example-shown in Figure 3 is an SS7 type network comprising 
a home location route (HLR)7 5 : a mobile service centre (MSC) 8 and a base station 
subsystem (BSS) 9. A mobile^station 10, which may be a mobile phone or personal 
digital assistant (PDA), is connected to-the network 2. 

25 The MSC 8 is responsible for routing voice and data circuits and packets to 

mobile handsets 10 that are in its geographic location at a certain time; whereas the HLR 
7 is responsible for the maintenance of subscriber profiles relating to subscriber 
location, i.e. which MSC location the subscriber is located within, and subscriber 
capabilities, v e.g. whether a subscriber is allowed access to voice, data etc. The BSS 9 

30 provides a management component for the radio infrastructure of the mobile network 2 
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and also manages the communication between switching infrastructure 7, 8 and the 
mobile handset 10, • * • ' * 



The transport mechanism 30 is responsible for receiving information from the 
5 SMX User 1, determining (via a HLR 7 where necessary) to which MSC 8 the 

subscriber is currently attached and transmitting the data to that MSC 8. Qnce the data 
has been received by the mobile handset 10 the. transport mechanism 30 will inform the 
SMX User 1. : . ; . 

10 In the opposite direction the transport mechanism 30 is also responsible for 

accepting data from a mobile handset 10 and transmitting it to the SMX User 1. 

The transport mechanism 30 may be managed and configured using a. system 
administration terminal (SAT) 12. This entity provides the human user interface to the 
15 transport, mechanism for management and configuration of the. SMX 6, and also for the 
other component layers of the mechanism 30. It incorporates an operation/ management 
control and monitoring interface to the transport mechanism 30. 

t , Figure 4 shows .the internal structure ofthe, SMX 6. It comprises a series of 
20 channels 13 .(CI,. C2, G3, . V CN) with associated treatments 14 ( Tl, T2, T3, ...TN). The 
service access point to the SMX 6 is defined as a relay layer or connection 15 which 
may be achieved using TCP/ IP or other netwprking protocols such as UDP/IP. The 
issues involved in the choice of relay layer are; . , 

• Speed 

25 • Reliability - - 

• Security > ■■■■■ 

• Quality of IP Network used to connect the SMX-User to the SMX 

• Personal Preference f ^ r = : 

The SMX 6 may also include a cache 20, which will be described later. 
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As shown for the case of one channel in Figure 5, each channel 13 is a set of 
core configuration data or attributes 16 (Al, A2, A3, ...AN) which when used with the 
related treatment-14 is designed to cater for the requirements of a specific SMX User 1 
which will use the S MX 6 for the transfer of data to a set of mobile entities. The 
■ 5 respective treatments 14 'define how data that is input to the SMX 6 from the SMX User 
1 is mapped on to a bearer protocol data unit (not shown), and include a set of definable 
subfields 17 (SI, S2, S3,-...SN) Typical layers 6 will contain approximately 50 such 
channels, each with related treatments, although this number can be changed according 
to specific situations and/ or applications. . 
10 ' -- .; ' ' 

Table 1 is an example of typical attributes and subfields that may be defined 
within a channel 13 and associated treatments 14 definition for a GSM network 
application. In this example' the channel 13 has ten attributes ( Al, ...A10) and two 
... associated treatments 14, "each treatment has nine subfields (SI ...S9). It will be 
15 appreciated that the number, and definition of the attributes and subfields will depend on 
the application requirements and the nature of the bearer technology to be used within 
the network. 











(Al) Connection 
Descriptor" 


Uniquelyidentifies the connection^definition on the SMX Layer. 


(A2) Connection 
Reference 


Used as a reference for connections that are open by default. ; 


(A3) Initial State 


Specifies whether the connection is open by default, therefore does not require an 
explicit opening by the SMX User (as per WDP etc.) 


(A4) End point Address 


Specifies the Endpoint Address that will be used for routing of MO messages to 
SMX Users. 


(A5) End point Type 


Defines whether routing of MO Data to this channel will be based on Service 
Centre address or based on Destination address. 


(A6) User Ack Reqd 


Specifies the timing of acknowledgement generation. See section 3 for a complete 
description 


(A7) GSM PID 


Specifies the PID that will be used for routing MO messages to the SMX User 


(AS) Password 


Specifies the password that must be specified in the connection attempt by the SMX 
User 


(A9) Connecting IP 
Address 


Specifies the IP Address from which the SMX User will issue a connection request 


(A 10) Alert Required 


Specify whether Alerts will be generated to the SMX User when MSs that were 
. unavailable -become available 


Msg Treatment I 








Treatment ID 


Identifies a treatment for data arriving from the SMX 
User to map this data to bearer formats 
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S2 . 


Input Data Type t 


Identifies the data coding that is used by the SMX User 
to transfer data to the SMX 


S3 


Output Data Type ' 


Identifies the data coding that must be used to transfer 
data to the MS 


S4 


GSM PID 


Identifies the GSM FID to apply to the bearer data 


S5 


Fragmentation Type 


Specifies whether to use binary or text based headers as 
defined in the WAP WDP Protocol Specification. May 
alternatively specify that data is to be truncated. 


S6 


GSM Reply Path 


Identifies whether replies to GSM SMS messages 
should be sent via the SMX or via the users default 
GSM Service Centre 


S7 


MWI Service Type 


Specifies the icon to be activated on the handset in the 
event of a GSM MWI message 


S8 


MWI Indication 
Group 


Specifies the way the handset should handle a GSM 
MWI message. E.G. Discard message. 


S9 


Message Class 


Specifies the GSM message class for a short message. 


Msg Treatment n 






SI 


Treatment ID 


Identifies a treatment for data arriving from the SMX 
User'to rnap this data to bearer formats 


S2 


Input Data Type , 


Identifies the data coding that is used by the SMX User 
to transfer data to the SMX 


S3 


Output Data Type 


Identifies the data coding that must be used to transfer 
data to the MS 


S4 


GSM PID 


Identifies the GSM PID to apply to the bearer data 


S5 , 


Fragmentation Type 


Specifies whether to use binary or text based headers as 
defined in the WAP WDP Protocol Specification. May 
alternatively specify that data is to be truncated. 


S6 


GSM Reply Path 


Identifies whether replies to GSM SMS messages 
should be sent via the SMX or via the users default 
GSM Service Centre- 


S7 . ... 


MWI Service Type 


Specifies the icon to be activated on the handset in the 
event of a GSM MWI message 


S8 ;. ; 


MWI Indication _ 
Group 


^Specifies the way the handset should handle a GSM 
MWI message. E.G. Discard message. 


S9 


Message Class 


Specifies the GSM message class for a short message. 



Table 1 



: The definition of each channel attribute: 13 and associated treatments 14 is stored 
on the SMX layer 6 . By varying the make-up of each channel and associated treatments, 
data received by the SMX 6 will be relayed between the user l and the mobile station 10 
in different manners. 



The SMX layer 6 supports both mobile originated and mobile terminated data. 
Mobile terminated data transactions, are defined as transactions„which are initiated by an 
SMX-User over the transport mechanism 30, and data is transferred from the SMX-User 
to a mobile user in the network. The SMX User 1 must typically specify only the source 
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information, destination information and data to be transferred. This information is used 
. by the layer 6 to ascertain as to which channel and treatment the user 1 wished to 
connect to and as a result in which manner the data will be transferred. 



5 The channels in ;the SMX layer 6 allow each SMX user 1 to open a connection 

for application specific message traffic:: This connection may be dedicated to processing 
service primitives up to a specified pre-defined capacity level. 

The connection definition is required for connection orientation of the 
10 connection between the SMX User and the SMX layer 6. Connection orientation is 
required to provide security services on the SMX layer and to allow the SMX layer to 
efficiently manage its interface to those SMX Users which are connected. Connection 
orientation also provides the mechanism for routing of mobile originated data to the 
appropriate SMX User 
15 • •; -. . , . v ■ . : - i : . •; • . , 

; In order for an SMX User, to open a connection and transfer data, the channel 
must first be defined on the SMX layer. As detailed above channel definition consists of 
specifying within the SMX layer, details of the SMX User that will be using the channel 
. and details of the treatments to be available to that channel. 

All data transfer transactions to the SMX 6 are performed as part of an 
application level session between the SMX User 1 and the SMX 6. On initiation of the 
application level session the layer, 6 identifies.the channel definition that is to be used 
for the lifetime of the session. Channels may be defined as having an initial state of 
25 open oran initial state of closed: Within the channel definition the following attributes 
relate specifically to initiation and closure of an application session; 

* Password/ connecting IP address ; ... . i 

• Initial state. . - ^ ' , . - : > 

30 The password and connecting lP address fields are used at initiation and 

termination of the session to verify that the connecting (terminating ) entity is legally 
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allowed to perform this operation. For channels having an initial state of closed a 
connection initiated request, as detailed in Figure 6, must first be issued by the SMX 
User 1 before any subsequent data transfer requests can be dealt with. 

5 On receipt 100 of a request to connect, the SMX layer 6 will verify 101 the IP 

address of the connecting party against the IP address specified in the channel 
definition. = • 

If verification of the IP address is successful;; the SMX layer will then verify 102 
10 the password provided by the connecting SMX User. 1 ~ 

* If password verification is successful, the SMX layer-will open the connection 

and send 103 an acknowledgement to the SMX Usier. ■ > < 

15 In the event that IP address or Password verification fails, the SMX layer will 

reject 103 the data transfer and respond, with a negative acknowledgement to the ~ 
connection request. : } • " _ ; 

Once a connection has been opened, or if the channel has . been defined as OPEN 
20 between the User and the layer 6, the User may initiate a data transfer request. Such a 
request is shown in the flow chart of Figure 7. - . - 

- 1 On receipt 105 of a request for data transfer the SMX 6 confirms 106 that a 
connection reference has been included in the request. Without such a reference the 
25 layer cannot allocate axhannel and as such rejects 109 the data transfer request. 

If the connection reference is included the layer 6 confirms 107 that a message 
treatment identification has been included. Without the message treatment identifier 
included the layer cannot allocate a specific treatment for the requested channel, and as 
30 . such must reject 109 the data transfer request. ' r < - : : :> 
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With both channel and treatment identified within the SMX layer 6, the transport 
mechanism 30 may transfer 108 the data to the network using the attributes and sub- 
types of the requested channel and treatment. 



5 In order to transmit data to a mobile user, the transport mechanism 30 must first 

find the MSC to which the subscriber is currently attached. In order to do this it must 
query the HLR for that subscriber. 

However, based on the topology of the mobile network, subscribers do not 
10 typically move between MSCs very often. For this reason, the SMX layer 6 may cache 
the MSC address for the subscriber once it is received from the HLR, and will continue 
to use this MSC address until such time as it fails to reach the subscriber at that MSC. 
The incorporation of a caching means 20 was shown in Figure 4. 

15 The purpose of this feature is to reduce the signalling traffic to the HLR and to 

improve the performance of the transport mechanism 30. 

The SMX layer manages the storage required for caching location information 
without user intervention. 

20 

The transport mechanism 30 also supports mobile originated (MO) data. Mobile 
Originated (MO )data is defined as data which is received. by the SMX layer 6 for 
onward transmission to an SMX User. Mobile originated data arrives at the SMX layer 
in the form of one or more Mobile Originated short messages. In order for an SMX user 
25 to receive Mobile Originated data it must first connect to the SMX layer using a 
previously defined channel. 

Routing of Mobile originated data to a specific channel is performed based on 
matching the contents of the data arid the addressing information provided in the SMS- 
30 MO with a channel definition. The following data items are an example of what may be 
used in the routing algorithm for GSM specific SMS applications. 
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Channel : 

• End Point 

* End Point type 

• Protocol Identifier (PID) ' 

Received Data as defined in known standards relating to bearer services. 

♦ Destination Address 

# Service Centre Address 

• PID 

10 # Application specific header contained within data, e.g. WAP Headers 

The routing algorithm as shown in Figure 8 operates as follows 
Mobile originated data is received 110 

1) Match 111 Service Centre Address of received data against End Point of channels 
15 ~ with end point type of Service fcentre Address 

a) If multiple matches 112, match PID 113 of received data against PID of 
matching channels 

(If there are still multiple matches 114 at this point, the SMX cycles 115 
successive Mobile Originated Data transactions across the matching channels) 
20 b) If no match then continue with step 2. 

2) Match 117 Destination address of received data against End Point of channels with 
end point type of MSISDN 

a) If multiple matches 114, then cycle 115 successive Mobile Originated 
transactions through the set of matching channels. 
25 b) If no match then continue with step 3. * 

3) Match PID 118 of received data with PID of channels 

a) If multiple matches 114, then cycle 115 successive Mobile Originated 
transactions through the set of matching channels. 

b) If no match then reject 119 ata 

30 
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Essentially the SMX layer 6 matches identifiers from the MO message with 
those in defined channels and relays the data using the predefined attributes and sub- 
types established in the matching channel. . 



5 Two major error cases are handled for mobile originated data transactions. The 

first case is where no channel is defined to which the data can be routed. In this case the 
mobile originated data is rejected with an error code indicating that the destination 
cannot be reached by this transport mechanism. The second case is where a channel 
exists but is not open at the time. In this case the message is rejected but with an error 
10 code indicating that the -destination is temporarily unavailable. 

Incoming MO activity by a subscriber is taken as an indication that that 
subscriber is available to receive data. : Therefore if an, alert is pending for a particular 
subscriber, then MO data from that subscriber causes the SMX to generate the alert. 
15 . 

The behaviour of a connection to. the SMX layer is defined by the settings 
associated with the connection definition being used. By altering the following channel 
attributes: . . ; 

♦ User Ack Required 
20 • End Point/ End Point Type/ PID, 

it is possible to further refine how the data interaction between user and network 
will be treated by the layer. The User Ack required attribute defines in the case of 
mobile originated messages whether or not the mobile originated data transfer must be 
25 successfully received by the SMX User prior to being acknowledged to the client. The 
various end point settings instruct the layer whether to route mobile originated data to 
the channel in question based on the Service Centre Address/ PID combination or based 
on the destination address information contained in the incoming mobile originated 
PDU. 

30 ' " ' 
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Figure 9 shows a single SMX data transfer request with the User 
Acknowledgement attribute set to required in the specific channel. The flow of data is in 
an alphabetical ordered sequence. The SMX layer 6 receives (A) a data transfer request 
from the network 2 which it transfers (B) to the SMX User 1. As acknowledgement is 
5 requested the layer 6 waits, until confirmation (C) froiri the User 1 that the data has been 
received is obtained, before acknowledging (D) the; original message to the network 2. 

Figure 10 shows the equivalent situation where the User Acknowledgement 
attribute has been set to not required. As such the layer 6 acknowledges (B) receipt (A) 
10 of the mobile originated data prior to successful receipt' (D) of the data from the SMX 
Userl. 

As detailed above each channel has an associated set of treatments. Treatments 
may be defined which alter the behaviour of the data transfer to the MS 10 such that 

15 additional functions can be implemented. Each treatment has properties associated with 
it, which causes the SMX layer to treat the data transaction in a particular manner. With 
relatibri to the example highlighted in Table 1 with reference to a GSM type network, 
the following list defines the effect that each of the treatment flags has on the data 
transaction. 

20 • Alert Required 

• Input / Output Data Types 

• Fragmentation Type 

• PID / Reply Path / MWI Flags / Message Flags 

25 The Alert Required setting instructs the SMX that in case of an error with a 

transmission using this treatment, it should generate an Alert to the; SMX User on this 
channel when the destination in question becomes available. Alerts may not always be 
capable of being generated by the SMX Layer. In the case where the SMX is unable to 
determine a state change in an MS, or in circumstances where the error is of a 

30 permanent nature, the SMX will generate an Alert PDU with the appropriate error code 
contained within it. 
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Figure 11 illustrates:an example where the SMX layer 6 receives (A) data from 
the SMX User 1 and forwards (B) it to the Mobile Station 10 attached to the network 2. 
An error occurs during the data transmission, either in the network 2 or at the mobile 
5 station 10, which is related (D) back to the SMX 6. The SMX layer 6 then decides that it 
is unable to transmit to this Mobile Station 10 and a failure indicator is returned (E) to 
the SMX User 1. The data will not be stored on the SMX layer 6 once the response is 
sent to the SMX User 1. / 



10 Figure 12 illustrates the further example where the SMX layer 6 receives (A) the 

data and forwards (B) it to the Mobile Station 10. A failure occurs during the data 
transmission, either within the network or at the mobile station. The SMX layer 6 then 
decides that it is unable to transmit to, this Mobile Station 10 and a failure indicator is 
returned (E) to the SMX User 1 as a response. The data will not be stored on, the SMX 

15 layer 6 once the response is sent to the SMX User 1. If the channel has been defined to 
generate alerts, the SMX Layer 6 will raise. (G) an alert to the SMX User 1 once the 
Mobile Station 10 becomes available (F). Generation of alerts may be enabled or 
disabled for a given connection. It is then at the discretion of the SMX User 1 to re-issue 
the data for that Mobile station 10. . . . * 

20 • • :.; • .- • • • ■ 

Figure 13 shows a flow chart which outlines a. possible internal mechanism for 
generation of alerts by the SMX layer back to the SMX User : 

in the event of failure 120 ... . . ■ 

25 Request 121 an alert from the HLR > 

If the resolution 122 of the error condition will not generate an alert in the HLR, 
Periodically PING 124 the handset for a configurable TIME PERIOD 

If a PING is successful 126, then generate the alert 128 to the SMX User 
30 If an Alert is received 127 from the HLR generate 128 an Alert to the SMX User 
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A PING operation is defined as a non-intrusive data delivery attempt to the 
handset. In the case of GSM, a PING is defined as a* Class 0 message with no data. i.e. 
an empty message is sent to the handset and no record, of the reception is kept by the 
handset. ; r 

5 ■ . - * 

The time period for which the PING operation is continued for, is defined as 
equal to the network Periodic Location Update Timer. This timer in the radio network 
(not shown) indicates the time period after which the mobile station must issue a 
location update operation to the HLR. Since an alert has been requested an alert from 
10 the HLR., this location update will cause the. HLR to generate it. 

Typical values for periodic location update timers vary from 30 minutes upward. 
The value usually depends on the coverage quality of the network, lower quality - lower 
value etc. • ; - - * : ' ■ 

15 • , i ♦ . * - ^ >\ • ■ u 

■ 1 In all cases one of three things v/iil happen, " 

L one of the pings will be^ successful, and an alert is generated 
2. the handset comes back into coverage, does a periodic location update , the HLR 
alerts the SMX and an alert is generated, 
20 3. the handset has powered off and the next time it powers on it does an IMSI-attach , 
the HLR alerts us and we generates alert. 

The Input / Output data Sub-types define for the SMX layer how it should 
interpret and translate the data from an incoming PDU to an outgoing PDU. The 
25 preferred valid combinations of Input data / Output data are as follows: 
0 ASCII Encoding - Binary- Encoding 

* ' Extended ASCII Encoding - Binary Encoding 

* Binary Encoding - Binary Encoding 

* ASCII Encoding - GSM Encoding 

30 * Extended ASCII Encoding - GSM Encoding 
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Table 2 illustrates an example of possible channel and treatment settings which 
may be used in a GSM network to alter the manner in which the data can be transferred 
using 7, 8 or 16 bit data. 

5 The Channel Profile is configured as follows: 



Connection Descriptor 


fhnnnpl Pi 

V> IIOIIIICJ L/ 


Connection Reference 


405 


Initial Slate ■ " * 


OPFM RY nPPAl I! T 


FnrfnAinl AHrfrp^^ 


1 ^ 1 O^ 7 7 


Pnfinniril Tvnp 


L/lO 1 l|Nr\ I I w IN /\L/U ivt_oo C. IN Lvr LJ1 !N 1 




I IQFP Ar^K" P FPll HPFPi 


GSM PramenJ ID 


A 


Password 


guesswhat 


IP Address 

1 1 r\ UUI I— - * t ' 


107 1 17 


\j\ ACC^O<> Troatmnnt Irl 


n 

U 


Infill r D*ifi Ti/n*» * ' * 
IHI7UI iViiwi i yuc 




\_/ui{jui L/ciui i ypc 


CC\/CK1D rrnMpnniMr: 
JCVtlNHi 1 trVHJLIlNO 


rviuunc i crmindicu r rotocoi iu 


u 


Fragmentation Type ■ 


uoMb j an da rd headers 


Rprvlv Pith - 

i\cpiy r.fiin - . .*■ * 


nCDl VDATU HlC A DI Cn 

KKr^Yr A ^H^DloAxSLfcU 


MNA^l Service Type ( 


Mwihax 


ivi wi iHuiLciiion oroup - 


m w i b to re M essa ge 




At PDT DCHI IIDCH 




(VI OrtO L*/\ jjII 


Mcstnop Trpslntpnt IH 

iviuja^v A I uiiiiicui All 


1 
i 


^nput Data Type 


A<jUI lEZ,lN \ UL/I IN vJ 


Ouimit Tvnp 


k>l/\ 1 E.C1ND1 1 dNV^LJLJ I IN 


Mobile Te*rmin*il("ri Pr/^i/ir*nl IH 


n 

u , _ 


Fragments! ion Tvpe 




Reply Path 


REPLYPATH_DISABLED 


MWI Service Type 


MWlFax 


MWI indication Group 


M WIStoreMessage 


Alert Required 


ALERT_REQUIRED 


Message Class 


NOM ESS AGEC LASS 


Message Treatment Id l - 


2 


Input Data -Type . . , 


BINARYENCODING 


Output Data Type 


EIGHTBITENCODING 


Mobile Terminated Protocol Id N : 


0 - - 


Fragmentation Type 


GSM STANDARD HEADERS 


Reply Path 


REPLYPATHJD1SABLED 


MWI Service Type' : • 


MWIEmail- 


MWI Indication Group 


MWIStoreMessage 


Alert Required 


ALERT_NOTREQUIRED 


Message. Class-" - \ » .* " ' ". - \ 


NOMESSAGECLASS 



Table 2 



BNSDOC1D: <WO 0049825A1 I > 



SUBSTTTUTE SHEET (RULE 26) 



WO 00/49825 PCT7IEOO/00024 

25 

Figure 14 shows the implementation of the specific example in the transfer of 
two packets of data (data packet 1, data packet 2) between the SMX User 1, the 
transport mechanism 30 and the Network 2. In data transfer data packet 1 the data is 
transferred (A) from the User 1 to the .SMX layer 6 using connection reference 405 and 
5 message treatment 0. The SMX layer compares these identifiers with the channel 

attributes and treatment subtypes and determines that the User 1 requires 7 bit ASCII 
data encoding, and transfers (B) the data accordingly ..On receipt (C) of - 
acknowledgement from the network, the SMX 6 acknowledges (D) successful 
transmission to the User 1. In data transfer data packet 2 the user 1 specifies the same 
10 connection reference 405, but uses requests (E) treatment 2. On comparison with the 
channel attributes and treatment subtypes the SMX layer 6 determines that the User is 
requesting 8 bit binary encoding and forwards (F) the data to the network 2 accordingly. 
In a similar manner it acknowledges (G, H) the successful transmission to the user 1*-- 

15 - The Fragmentation Typje setting tells the SMX 6 how it should fragment the * 

incoming data into bearer PDUs. The SMX layer 6 supports multiple fragmentation 
schemes for mobile terminated data transactions: Each channel may have a C 
. fragmentation scheme defined for it. The preferred, supported fragmentation schemes^are 

as follows: " " - - ; 

20 * GSM (as defined in GSM ,03 ,40) v' 

• . WAP Short Binary . . ... ?. „ . . . ; 

WAP Long Binary . ~" '■""*";/"• 

• WAP Text . -. - 

25 By varying the settings associated with the fragmentation type it is possible to 

either fragment a message into a series of shorter messages, or to concatenate a series of 
short mobile originated messages into a single block before transmission to the SMX 
. User. In order to cater for errors in the network etc., the SMX layer wkiis a configurable 
time between fragments before assuming that a transmission has failed. Once this time 

30 has expired the SMX layer assumes. that the transmission has failed and abandons the 
reassembly . The data thus* far received is thrown away and subsequent fragments 
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arriving at the SMX are ndt Accepted. Figure 15 shows an example of how a data block 
submitted via a data transfer request may be fragmented into multiple messages. The 
SMX 6 receives (A) the data block, and separates it into two separate messages. After 
sending (B) the first message to the network 3, the SMX waits for a response (C) from 
the network confirming receipt of the first message before sending (D) the second 
message; It is only- on receiving (E) confirmation from the network that the second 
message has been received by the network that the SMX confirms (F) successful 
delivery of the data block to the SMX user 1. Figure 16 shows an equivalent situation 
for the concatenation of multiple 1 mobile originated short messages into a single block 
before transfer to the SMX User 1. Message A is received and acknowledged to the 
network. Message C is then received and the two messages (A, C) are concatenated into 
a single message D and transferred to the User 1. In a similar fashion to that outlined 
with reference to Figure 15; it is only on receiving (E) confirmation from the User 1 that 
the message D has been received that the network is acknowledged (F). ; 

The SMX provides resistance to transmission errors in mobile terminated data 
transmissions by selectively re-transmitting fragments of the data that have failed. The 
selective retransmission algorithm is based on the following data items which must be 
configured in the system : r ■ ^ 

* Maximum failures perdialog: this number indicates the total number of failures 
across all fragments of the data bloc that will be tolerated before abandoning the 
transaction, e.g.' if set to 5, then a total 6f 5 failures on all fragments transmitted to 
date will cause the entire transaction to fail. 

• Maximum failures per fragment: this number indicates the number of failures on a 
particular fragment that will be tolerated before the entire transaction is abandoned, 
e.g. if set to 3, then 3 sequential* failures on the same fragment will cause the entire 
transaction to fail. Default setting is preferably set to 3. ' 

The algorithm then operates as shown in Figure 17. In the event that there is a failure 
detected 130 in the transmission 130 of a fragment 'the layer 6 checks to see whether 
either the maximum failures per dialog or maximum failures per fragment 132 has been 
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exceeded. If .these have been exceeded then the message is discarded 134. If this is not 
the situation the error code received is compared 133. to a list of those available for 
selective retry. If it is available for selective retry then the message is sent 130 again, 
otherwise the message is discarded 134- 
5 . t ■ ■ ■ . , t . • . - 

The PID, Reply Path, MWI Service Type r M\yi Indication Group, and Message 
Class fields are used to set the values of various fields in the GSM SMS Transport PDU* 

Connection termination resets the connection to the inactive state. Once a 
10 connection has been terminated, it must re-established as described above before any 
further data transfer may take place. , . 

The primary function of the SMX 6 within the transport mechanism 30 is ta- 
rnediate the technology specifics of the mobile station interface to a consistent 
15 technology independent interface to the SMX User 1. 

. * The SMX layer is designed to fully conform to the WAP WDP protocol. The 

SMX layer is specified in terms of attributes and treatments associated with specific, 
channels. The structure of these is such that by omitting or altering certain optional . 
20 , parameters the fprm and. niethod of the data transferred .will be as required for 

conformance to the WAP WDP protocoI. The implementation of WDP on the SMX 
. layer* is- achieved' by the setting of specific connection, treatment and PDU fields as 
follows, ^ . 

c 1 . . . : Connection is set to OpenBy Default, no explicit connection set-up is needed. 
25. 2.. Fragmentation scheme is set to WAP Short or WAP Long. 

, 3. Data. Transfer PDUs do not include, a User Reference, therefore no 
acknowledgement will be generated. . f . . 
4. Data Transfer PDUs do include Source and Destination port numbers. These will be 
encoded as, per WDP by the SMX. , ; ..... ,. u . ; . . 

30 5. User Ack Required set to NotRequired, hence for MO data, the SMX will 

. acknowledge to the handset without expecting a confinnatipn ftqjn the SMX-User. 
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An example of a possible channel profile configuration is given below in Table 3: 



Connection Descriptor 


Channel WDP 


Connection Reference .. 


27 


Initial State 


OPEN BY DEFAULT 


Endpoint Address 


353668396710 


Endpoint Type 


SERVICECENTRE ADDRFS^ FMDPnT 


User Acknowledgement Required 


USER ACK NOTREOIJTRFD 


GSM Protocol ID 


0 


Password 


mylovelywap 


IP Address 


192.1.2.3 


Message Treatment Id 


0 ' ■■ 


Input Data Type ...... 


BINARYENCODING 


Output Data Type 


EIGHTBITENCODING 


Mobile Terminated Protocol Id 


0 


Fragmentation Type 


WAPSHORTBINARYHEADERS 


Reply Path 


REPLYPATH DISABLED 


MWI Service Type 


MV/IEmail : 


MWI Indication Group 


MWIDiscardMessage 


Alert Required 


ALERT NOTREOUIRED 


Message Class ■> * 


NOMESS AGECLASS 



In a similar manner to that outlined above by simply inputting which is the required 
channel and treatment the SMX layer will determine how the data is to be treated. 



The examples of SMX described thus far have been specific examples of the 
application of the SMX layer within a transport mechanism relating to a GSM specific 
network . By redefining channels and their respective treatments in a different manner it 
is possible to utilise the SMX Ia>/er as an interface to different bearer networks such as 
USSD, GPRS and IS41 networks. The input by the SMX user 1 will be the same for all 
bearer networks. On receipt of the connection reference and treatment identification the 
SMX layer determines which channel the User 1 is requesting, and as such how the data 
should be transferred. All that is required is a re-defining of the channels and treatments 
so as to make them compatible with the relevant networks. It will be appreciated by 
those skilled in the art that in certain circumstances multiple bearer networks may need 
to be supported. Such a situation is shown in Figure 18 where a single SMX layer 6 is 
used by the SMX User 1 to send data over a variety of bearer networks. By adding 
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specific channels and related treatments to the SMX layer 6, the SMX layer becomes 
compatible with the various networks. The User 1 inputs a data request which, in a 
similar fashion to. that described with reference to the aforementioned specific GSM 
network, is allocated a relevant channel. This allocation or choice of channel then 
5 determines how the data is transferred to the bearer network. 

Roaming / Foreign subs 

The transport mechanism 30 preferably supports transmission of data to home 
10 PLMN subscribers roaming in foreign networks, as well as transmissibn of data to 
foreign subscribers roaming in the home PLMN or inrfo reign PLMNs. 

Operations and Maintenance 

15 ' The SMX layer, may *be configured and maintained using the system application 
terminal (SAT). The SAT is preferably a JAVA™ application. As the SMX layer is 
preferably only one layer of the many available within the transport mechanism it is 
preferred that the SAT may implement the configuration and operation of the SMX 
layer as well as other layers within the transport mechanism. The SAT is designed to be 

20 capable of being run on a separate platform from the transport mechanism 30 and is 

preferably written in JAVA™ so that it can be run from any JAVA™ Virtual Machine™ 
(VM). Alternatively, the SAT may be written in any object orientated language. 

There are three main areas of functionality within the SAT: 
25 • Monitoring 

* Configuration 

• Control of the Application 

The monitoring area is used for the inspection of current configuration and 
30 monitoring of fault logs / event histories. 
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The configuration area is used for the creation on new sets' of configuration data 
and modifications to existing 1 data. 

The Application control is used for starting arid stopping the application as well 
as activating configuration updates on thesystem. 

Access to the SAT Functions may be protected by User Ids and user types. Users 
may be assigned to be either View users (with access only to Monitoring features or 
Super users with access to all features. Management of users is a feature only available 
to Super users. 

The SAT breaks the user interface to- the SMX in terms of the main areas within 
the SMX. These areas are Channels - where the application level interface to external 
systems is covered, Network — Where the connectivity of the SMX to the SS7 network 
and the IP network are covered and Application — where the internal details on the SMX 
are covered. Within each of these areas specific items are available either for 
configuration or monitoring or both. ' ^ : 

The operation of the SMX layer is determined by a set of configuration data. 
This data defines inter alia, the set of channels available, treatments on those channels, 
the SS7 network configuration etc. 

In order that updates to configuration data may be performed without impact to 
the operation of the system, the; SMX layer maintains two sets of configuration data, 
Primary data and Secondary data. : , 

Xhe SMX operates on the-Primary data, while the Secondary data is worked on 
by operation^ staff. Once the Secondary configuration is ready for use by the SMX, a 
super user may instruct the SMX, via the SAT to switch its configuration to the 
Secondary data. At this point the SMX will begin operation with the Secondary data. 
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Both the Primary and Secondary configuration ,data are maintained on the 
system at this point. Once the Super user is satisfied that the new configuration is 
operating correctly, the Super user may synchronise the Primary and Secondary 
configuration data on the system. The result of this operation is that the Primary 
configuration is permanently, removed and a new Primary set is created from Secondary 
set. Prior to the synchronise, if the Super user was not satisfied with the operation of the 
new configuration, the SAT may be instructed to switch the configuration back from 
Secondary to Primary. This has the effect of restoring the previous configuration data. 

During the time between switch forward and synchronise or switch back no 
further configuration changes may be made. Once a synchronise or a switch back have 
been performed, the Super user may make further, changes to the Secondary data. A 
super user may perform a switch forward, synchronise or switch back independently of 
whether the system is running or not running. Independently of the switch, synchronise, 
5 switch scenario, a super user may stopjand^tart the system at any point. .< 

Based on the set of areas and items listed abpye the SAT, provides a data entry 
interface for entry of the appropriate data. The SAT also provides a level of validity 
checking on the data to ensure that legal values only are entered and that any ^ 
relationships between various data items are maintained. - 

Generally configuration operations allow for the following operations on ail data 

• Add ...To add new items to the configuration . 

* 5 • Delete ...To remove items from the configuration - - 

• Modify ...To alter the definition of items in the configuration 

Additions,' Deletions and Modifications to system configuration are effected on to the 
' running system as described above'with reference to the control of the application. 
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Billing Module - 

The SMX layer may additionally be modified to incorporate a billing module. 
5 Figure 19 shows th6 incorporation of such a billiiig cache 200 into the SMX layer 6 that 
was previously described with reference to Figure 4. When activated, each message 
transaction between the mobile user and the VASP generates a toll ticket which suitably 
tracks or identifies the transaction between the user and VASP. These toll tickets are 
configurable for given channels; The format options are defined via the SAT and the 
10 channel administrator may select from a set of pre-defined fields, which are to be 
included in the toll ticket/Available fields include the following: 

• Toll Ticket Type - - 

• Channel ID 

15 • Treatment ID ; - : • '< •' ' 

• Originating Address 

• Destination Address 

• MSC Address ' " ■ 

• Status of Delivery . : . 
20 • ErrorCode - 

• Submission Tirheistemp • . ; . 

• Delivery Timestarnp 

• Message Length 

• Message Priority 

25 • Message Reference • ' i! 

In addition the delimiter character which is used to separate fields in the billing 
record, such as for example a comma, may also be configured by the administration 
interface. This generation of toll tickets may be disabled for a channel, via the 
30 administration interface; In the case where toll ticket generation is disabled, no 
permanent record of the short message transaction is kept. \ 
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The billing cache typically stores the information ticketed for predetermined 
time. If this timers overrun the billing cache may run out of space. If this occurs the 
oldest data is preferably overwritten first. There is no interrogation of the billing cache, 
transaction details are simply transferred to the billing cache which then stores the 
information. Subsequent analysis of the information stored is processed after a 
download from the billing cache. Figure 20 sho\vs the incorporation of a typical 
platform 210 which may access the billing cache over a local area network, or 
alternatively over a wide area network. The processing and analysis of the billing 
caching is done on a standard network billing system,; within the platform 20, Any one of 
a number of standard transfer protocols may be used to interrogate the billing cache. The 
cache is completely customisable and is preferably capable of storing data for up to 7 to 
15 days. This storage capability, as will be appreciated by one skilled in the art, is 
dependant on the disc storage capability, and can be modified accordingly. The 
combination of the cache 200 and billing system 210 forms the billing module. 

As discussed previously on completion of a short message transaction, the SMX' 
layer generates a toll for the specific transaction. This toll ticket is written to the 
currently active ticket file. The toll ticketing subsystem (or billing system) is responsible 
for managing the space allocated on the system for ticket logs. The following 
configuration defines a typical storage of ticket logs on the system.,, r 



Field 


Definition 


Ticket Directory 


Path name of the directory where the 
tickets logs are stored . ; 


Ticket Log Size 


Maximum number of ticket log files that 
can be stored 


Ticket Log Duration 


. Maximum time duration a ticket log file 
can be open and have new log entries 
,.added to it r-: 


Maximum Ticket Logs : r ^ . 


Maximum number of log files that can be 
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stored on the system 



Based on this information the ticket (the toll ticketing subsystem) swaps over to a new 
log once the current log reaches the defined size or has been opened for the defined 
duration. The ticket manager then removes older logs upon reaching the maximum 
number of logs or maximum number of log entries. 

Each toll ticket will indicate the event to which it relates (for example message 
submission, unsuccessful delivery attempt, successful delivery attempt) and will contain 
information relating to the source, destination, submission time, delivery time etc.. As 
discussed previously the system is typically defined with adequate resources to store up 
to 7 days worth of toll ticket logs. External systems such as Customer Administration 
and Billing System (CABS) may connect to the SMX layer at any point to transfer the 
toll ticket log stored in the billing module. The standard transfer methods supported 
include TCP/IP. / ^ 

It is also possible to adapt the billing module for real time ticket streaming. 
When this is chosen tickets are typically written to an external system using a TCP/IP 
socket connection. In this scenario no storage of the toll tickets is performed by the 
billing module cache rather the information is immediately transferred to the external 
procession. 

Robustness 

The SMX server is resilient to error conditions which may occur from time to 

time, 

The following conditions are catered for : 
1. Software Faults 

In the event of a software fault occurring within the SMX application, the fault will 
be logged as a serious event, visible to the SAT user. If the SMX determines that it 
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can continue operation despite this fault then it will continue. Otherwise the SMX 
application will reset itself and then continue operation. 

2. Hardware Faults 

In the event of a hardware fault, the SMX will raise an event related to the fault and 
5 if possible it will continue operation. If it cannot continue operation, it will reset 

itself and then attempt to continue operation. 

3. Power failures 

In the event of a power failure, on return of power the SMX will restart itself, restore 
temporary data and attempt to continue operation. r 
10 4. SS7 Network Errors 

SS7 Network errors are handled as per Hardware / Software errors as described 
above. In addition the SMX will utilise standard SS7 techniques (alternate routing, 
load sharing etc.) to continue operation. 

5. Platform Resource Limitations 

15 The SMX layer is designed to use only pre-defined amounts of layer resources. 

However in the event that all layer resources of a particular type are used, the SMX 
will attempt to free resources in order to continue operation. Ultimately the SMX 
. application will reset itself and attempt to continue operation. 

6. Congestion control may be applied so as to minimise the effect of overload on the 
20 transport mechanism. 

For all of the above circumstances the SAT User is informed by way of top level 
alarms on the SAT screen as well as specific events generated in the relevant areas of 
the SAT. In the case of serious platform, application or interface failures the system will 

25 trigger alarm relays to notify operations staff that there is a problem. Alarm relay 

triggering is configurable and may be configured via the SAT. In order to monitor the 
operation of the system a set of high level alarm status's are presented to all SAT users. 
These alarm status's are presented relating to the three major areas of the system , 
Channels, Network and Application, These alarm status's are presented in the form of 

30 colour coded information, red indicating a serious problem, orange indicating a less 
serious problem and green indicating no problem. 
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For each of the three major areas of the system and for all appropriate sub-areas 
and items within the system a detailed log is maintained for all the event reports 
generated by the system relating to these areas"/ items. Again the event codes are colour 
coded, fed indicating a serious problem,- orange indicating a less serious problem and 
green indicating no problem. 

Advantag es - « : ?■ ** 

By using the industry standard TCP/IP LAN interface it is possible to provide 
access to the SMX layer -in a 1 technology independent manner that supports both IS41 
and GSM. The SMX layer is*Wireless Application Protocol (WAP ) compliant and by 
providing a WDP interface layer it is easier for Value Added Service layers to make the 
transition to WAP compliance. The underlying- bearer of the SMX is the Short 
Messaging Service (SMS ) which has support over both IS41 and GSM networks, but is 
also upgradable to support USSD and GPRS. The incorporation of the SMX layer 
within a transport mechanism pr&vides a number of advantages to the user: 

• The VAS application has full control-over the data delivery 

• Dedicated access ensures a better grade 'of service per delivery 

• As the system is transaction based, and not reliant on store and forward, performance 
is improved < 1 .: . - 

• There are less nodes for the operator to manage 

• The VAS can be provided in an more cost effective manner, resulting in better 
margins for VAS providers 

• The integration of WDP provides a seamless access to WAP technology. 

The words "comprises/comprising" and the words "having/including" when used 
herein with reference to the present invention are used to specify the presence of stated 
features, integers, steps or components but does not preclude the presence or addition of 
one or more other features, integers, steps, components or groups thereof. 
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Claims 



1. A layer (6) in a digital cellular data packet transfer mechanism (30) for use with 
a digital cellular telecommunications system (11) comprising: 

5 : a ) means (105) for receiving a data transfer request from a service provider 

(1), > 
b) means (106) for comparing a first identifier on said data transfer request 
to a series of stored reference values contained within at least one 
communication channel, 
10 r c) means (107) for comparing a second identifier on said data transfer 
request to a sub-series of stored reference values, 
, d) means for determining an appropriate channel and treatment from said 
, first comparison and said .second comparison and allocating said data 
transfer request to the^apprppriate; channel. 
15 - • . . • - : : . • . . ■ ■ ■ - . • . . . - 

2. : * The -layer as claimed.in claim 1 further comprising: 

.a) means (100) for obtaining a connection request from a service provider 
b) means (101) for comparing an identifier of said service provider to a 
predefined series of stored identifiers, 
20 c) means (102). for comparing a check parameter from said service provider 

to a. predefined series of check, parameters, and 
d) means (103) for accepting said connection request when said identifier 
and said check parameter arean accordance with the stored identifier and 
predefined check parameter. V l - ; 
25 ... ■ 

3. The layer as claimed any preceding claim further comprising: 

a) means (110) for receiving a mobile originated data request from a mobile 

. ; \ . .. , USer (10), • , , ,. . ; . 

,b) means (1 1 1) for eomparing. a .first mobile originated ^identifier with a third 
30 , stored reference value contained with at least one communication 

channel, ,.*.!■:• . *-'■::> 
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: c) means (112) for determining if when first mobile originated identifier 
corresponds with the third stored reference value whether said third 
stored reference value is stored in a multiplicity of communication 
channels, 

d) means (117) for comparing, a second mobile originated data identifier 
with a fourth stored reference values contained with at least one 
communication channel, if the first mobile originated identifier does not 
corresponds with the third stored reference value, 

e) means (118) for comparing a third mobile originated data identifier with 
a fifth stored reference contained with at least one communication 
channel, if the second mobile originated identifier does not corresponds 
with the fourth stored reference value, and means (119) for rejecting said 
mobile originated data request if the third mobile identifier does not 
correspond with a fifth stored reference value, 

f) means (114) for determining if the second or third mobile identifiers 
correspond with a fourth or fifth stored reference value respectively, 
being stored in a multiplicity of communication channels 

g) means (115) for cycling successive data requests to a service provider 
through successive respective communication channels if the second or 
third mobile identifiers correspond with a fourth or fifth stored reference 
value respectively, being stored in a multiplicity of communication 
channels, 

h) means (116) for transmitting the data request to a service provider if the 
first or second or third mobile identifiers do not correspond with the third 
or fourth or fifth stored reference value, being stored in a multiplicity of 

* communication ciiahneis. 



4. The layer as claimed in any preceding claim further comprising means (13) for 
configuring the data transferrequest according to a set of predefined attributes 
(16)-aridWfields(17)/ : " v • ' - 
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5. The layer as claimed in any one of claims 1 to .4 further comprising a cache 
means (20), said cache (20) suitable for storing the location of the mobile user 
10 5 such that said cached location will be used for forwarding data to said mobile 
user until such time as said data cannot be delivered. 

6. The layer as claimed in claim 5 wherein the identifiers are selected from one or 
more of the following; . : . .... 





a) 


toll ticket type 




b) 


channel ID 


10 


c) 


treatment ID. 




d) 


originating address . t 




e) 


destination address 




, f) 


MSCMdress 




g) 


status of delivery . 


15 ... . 


h). 


error code . , 




i) , 


submission time stamp 




J). 


delivery tirpe stamp 




k). 


message length . 




0 


message priority 


20 




message reference 



The layer as claimed in any one of claims 1 to 6 further comprising a permanent 
transaction record storage, the storage adapted to record and store identifiers 
associated with the data transfer request, . 

A database structure for use in a digital cellular telecommunication system 
comprising: 

at least one channel (13), having one or more associated treatnients(14) whereby 
each channel comprises a series of definable attributes (16) and each treatment 
comprises a series of definable sub-fields (17) such that the definition of the 



7. 



25 



30 
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attributes and sub-fields determines how data is transferred within the digital 
cellular network. 

9. The database structure as claimed in claini 8 whereby the definition of the 
attributes and sub-fields within specific channels and treatments is such that the 
database can be used with bearer networks selected from one of more of the 
following: 

* a) Cellular Digital Packet Data (CDPD), 

b) Global System for Mobile Communications (GSM) Short Messaging 
Service, 

c) GSM Unstructured Supplementary Service Data (USSD), 

d) GSM General Packet Radio Service (GPRS), " 

e) iDEN (Integrated Digital Enhanced Network.) Short Messaging Service, 

f) IS-136 GUTS (General UDP Transport Service), 

g) IS : 136 Short Messaging Service, (Time Division Multiple Access), 

h) IS-637 Short Messaging Service, (Code Division Multiple Access), 

i) or other CDMA/ TDMA bearer networks. 

10. The database structure as claimed in any one of claims 8 or 9 further comprising 
storage means adapted to store identifiers associated with transferred data within 
a digital cellular network. 



11. A transport mechanism (30) suitable for use in a digital cellular network (11) 
comprising: 

a) " transport and relay layers (5) for transporting and relaying data on a 

bearer network, and further comprising 

b) the layer (6) as claimed in any one of claims 1 to 7. 

12. A digital telecommunication system (11) comprising: 

a) a service provider (1) 

b) a telecommunication network (2) 
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c) a transport mechanism (30) for transferring data between the service 

provider and the network(2) whereby the transport mechanism comprises 
a first layer (6) suitable for interfacing with both the service provider and 
any other component layers ( 5) of the transport mechanism (30), the first 
5 layer (6) incorporating means (13, 14) for determining how data received 

from, and data destined for, the service provider (l),is transferred. 

13. The mobile telecommunications system as claimed in claim 9 whereby the first 
layer (6) comprises a series of channels (13),. each channel having at least one 

10 treatment (14), the channels (13) and associated treatments (14) each comprising 

a set of data fields for determining how data allocated to the specific channel and 
treatment should. be processed. r 

14. The system as claimed in any one of claims 12 to 13 whereby the definition of 
15 . the data fields related to each channel (13) A and associated treatments (14) 

provides an interface to the system, which is independent of the underlying bearer 
service. t 

15. The system as claimed in any one of claims 12 to 14 whereby the definition of 
20 the data fields (16, 17), related to each channel (13) and associated treatments 

(14) enables the service provider of the system to transfer data in a transaction 
orientated manner. 

16. The system as claimed in any one of claims 12 to 15 whereby the number and 
25 definition of the attributes (16) and.subfields (17), is dependant on the 

application requirements and nature of the bearer technology. 

17. The system as claimed in any one of claims 12 to 16 whereby the attributes may 
be defined with reference to one or more of the following fields: 

30 a) Connection Descriptor 

b) Connection Reference 

c) initial State " .. : < : • .• 

d) Endpoint Address 
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-e) 

g) 
h) 
0 
j) 



Password 

Connecting IP Address 
Alert Required. 



Endpoint Type 
User Ack Reqd 
GSMPID 



IS. The system as claimed in any one of claims 12 to 17 whereby the subfields may 
be defined with reference to one or more of the following fields: 
a) Treatment ID 



d) GSMPID 

e) Fragmentation Type 

f) GSM Reply Path 

g) MWI Service Type ^ 

h) MWI Indication Group r 

i) Message Class 

19. The system as claimed in any one of claims 9 to 18 further comprising a storage 
means for recording and identifiers associated with the data transfer between the 
service provider and the network^ ' - 



20. The system is claimed in claims 9 to 19 further comprising means to interrogate 
the storage means, said means adapted to transfer information from the storage 
means to an external network processor. : 



21. The system as claimed in any one of claims 12 to 20 further comprising means 
for operating and configuring the system including a remote operation and 
management interface, access to which is preferably via a system administration 
terminal (12) which may be operated using remote object invocation. 

22. A method- of determining how data should be transferred between a service 
provider and a network in a digital cellular network system comprising the steps 



b) 
c) 



Input Data Type 
Output Data Type 



of :'- 



a) 



receiving (105) a data transfer request from a service provider 
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comparing (106) a first identifier on said, data transfer request to a series 
of stored reference values contained within at least one communication 
channel , 

comparing (107) a second identifier orisaid data transfer request to a sub- 
series of stored reference values, 

determining (108) an appropriate channel and treatment from said first 
comparison and said second comparison and allocating said data transfer 
request to the appropriate channel. : , 

10 23. The method as claimed in claim 20 further including the preliminary step of 
making a connection comprising the steps 6f:' : '~ 

a) obtaining (100) a connection request from a service provider 

b) comparing (101) an identifier of saidiservice provider to a predefined 
series of stored identifiers, 

15 r. c) comparing (102) axheck parameter from said service provider to a t . 
v , predefined series of check parameters 

d) accepting (103) said connection request when said identifier and said 
check parameter are in accordance with the stored identifier and 
predefined-check parameter. ; . 

20 : •. -. - 

24. The method as claimed in claiin 22 or 23 further comprising the steps of 

a) receiving (110) a mobile originated data request, 

b) . comparing (111) a first mobile originated identifier with a third stored 

reference value contained with at least one communication channel, 
25 . c) ( determining (112) if when firstmobile originated identifier corresponds 

with the third stored reference value whether said third stored reference 

value is stored in a multiplicity of communication channels, 
d), . comparing (117), a second mobile originated data identifier with a fourth 

stored reference values contained with at least one communication 
30 channel, if the first mobile originated identifier does not corresponds with 

the third stored reference value, . . : ^ 
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e) comparing (118) a third mobile originated data identifier with a fifth 
stored reference contained with at least one communication channel, if 
the second mobile originated identifier does not corresponds with the 
fourth stored reference value, and rejecting (119) said mobile originated 
data request if the third mobile identifier does not correspond with a fifth 
stored reference value, 

f) determining (114) if the second or third mobile identifiers correspond 
with a fourth or fifth stored reference value respectively, being stored in a 
multiplicity of communication channels 

g) cycling (115) successive data requests to a service provider through 
successive respective communication channels if the second or third 
mobile identifiers correspond with a fourth or fifth stored reference value 
respectively, being stored in a multiplicity of communication channels, 

h) transmitting (116) the data request to a service provider if the first or 
second or third mobile identifiers do not correspond with the third or 
fourth or fifth stored reference value, being stored in a multiplicity of 
communication channels. 

25. The method as claimed in any one of claims 22 to 25 further including the step 
of transferring (108, 115, 116) said data to a destination address in a manner 
according to a set of predefined attributes and treatments stored in said 
appropriate channel. 

26. The method as claimed in any one of claims 22 to 24 further including the step 
of recording information associated with transfer of data between the service 
provider and network, and further processing said recorded information to 
generate a transaction history associated with said data transaction. 
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